The method and structure of the implementation of event driven networks fundamentally differ from one another in the type of notification system, type of data storage, location of data storage, security, routing and network topology.
In currently used e-commerce solutions, including peer-to-peer networks, a “pull notification” system is used for deriving a match between the requirements of a buyer and a seller. In a pull notification system, the buyer issues a buy request, which is then matched against the seller's profile at that point in time. However, if a seller does not have a matching product or service at that point in time, the seller has to wait until the search is again initiated by the buyer. However, this method reduces the incidence of a match at the time of posting of the changed attribute and also reduces an eventual match between the buyer and seller. Even if the buyer automates the search to be conducted at short periodic time intervals, during that short time interval the seller loses his or her opportunity to complete the transaction of the product or service if the seller's product or service was not posted for sale during that time interval. Also, if a seller updates their profile and places a product or service on sale that would have matched the buyer's requirements just after a search is conducted by the buyer, the transaction will again not be completed. The seller will now have to wait until the next automatic or manual search is conducted by the buyer after a predetermined time interval. In today's e-commerce networks containing thousands if not millions of users, a fraction of a second lost in the posting of information by sellers on the availability of their product or service can potentially be a significant lost sale opportunity for that seller. In summary, the “pull notification” strategy that is buyer-driven places some sellers at a disadvantage in e-commerce networks. Also, in a large network of users, if automated searches are set by users to be conducted at short periodic time intervals, the network traffic may get over-loaded as a result of the frequent automated notifications.
Typically, in currently available pull notification solutions, all transaction data, for example the details of the buyer and seller are stored in a central database. The user, which may be the buyer or the seller, logs on to the system and searches this central database to determine a match for the user's requirements. When the system finds a match for the user's query, the system notifies the user. If a match is not indicated at that point in time, the user has to re-initiate the search at a later point in time. In the above solution, a central database is required; the local databases of the users' user applications are not utilized for storing data. Even in the case of a pull notification system with a distributed database, typically intelligence is located centrally. A central controller would conduct the predetermined periodically-timed searches of the buyer and would execute the transactions.
In the present push notification invention, the event driven network is brought to the user, thereby empowering all sellers. The user does not have to actively conduct search queries at short periodic time intervals for buy or sell transactions. The user only needs to feed the changed attributes in the attribute profiles of the user's application for conducting a transaction. Once the user changes the buy or sell attribute profile, the notification of the change in attribute is automatically broadcasted in real time to all users of the event driven network. This automatic broadcast of attribute changes in this event driven network will hereafter be referred to as push notification. The user can change the user's attribute profiles even if the user application is not logged on to the event driven network. Once the user application logs on to the event driven network, the notification of the change in attributes is sent to all other users in the event driven network.
The following example illustrates the differences between the pull notification method of existing solutions available today in the market from the push notification system of this invention that is implemented in real time and is event driven. For example, consider an e-commerce event driven network used for buying and selling goods. A buyer desires to purchase a book at a certain sale price using this event driven network. The buyer would send out a search request on the event driven network to find a seller for that book at that sale price at that point in time. Assume that the first search is conducted at 12:00 P.M. and no sellers have that book at the sale price at 12:00 P.M. The buyer then requests the network to automatically conduct a search for the book at one-hour intervals. Therefore, the next search will be conducted at 1:00 P.M. Assume that at 12:59 P.M., Seller A posts the required book at that sale price in the event driven network, and that Seller B posts that book at that sale price at 1:01 P.M. on the same network. When the automated search is conducted at 1:00 P.M., only Seller A's book will show as available for sale on the network to the buyer. Assume that the buyer needs to take a decision on buying the book by 1:30 P.M. In a pull notification system, the transaction for the purchase of the book will be executed through Seller A, because the buyer was not made aware of the availability of the book by Seller B at 1.01 P.M. as the search of the book will not be re-conducted by the buyer from 1 P.M. to 1.30 P.M. Even though Seller B posted his or her book on sale on the network at 1:01 P.M., i.e. just 2 minutes later than Seller A, Seller B lost the opportunity to sell the book to the buyer. This is the disadvantage of the typical pull notification system of currently available solutions. The current pull notification system places some sellers at a disadvantage. However, in the event driven push broadcast notification of this invention, there is no need to conduct a search periodically at predetermined time intervals. If a seller posts a book or updates their attribute profile at a point in time after the search query is conducted but before the execution time of the transaction and where the book meets the requirement of the buyer on sale, the new information is pushed out and broadcasted to other users, i.e., to potential buyers in the network. Hence, under this invention, Seller's B notification of the book at the sale price will be sent to the buyer at 1:01 P.M. and the buyer now can choose between the books of Seller A and Seller B as the buyer will execute the transaction for the purchase of the book at 1:30 P.M.
It may appear that the use of a push notification strategy will result in the event driven network to be flooded with update messages. In reality, the network traffic generated as a result of notification updates of sellers is less than network traffic generated by a majority of the buyers that conduct automated searches at short periodic time intervals in a commercial network using the conventional pull notification method. In current commercial pull notification system networks, the buyer does not have an incentive to place a time limit for the period of time such periodic searches are to be conducted. However, the shorter the time interval, the greater is the traffic burden on the network. Hence, the current pull notification system network is heavily burdened with redundant automatic searches that are sometimes conducted even after the buyer has decided not to purchase the product or service.
Under this push notification invention, there is there is no need for any centralized intelligence for performing the matching of attributes. The intelligence for performing attribute matching lies in each user application.
Also, under this push notification invention there is no need for a large centralized database to store the user's attribute information. The user's attribute information is stored either locally in the device hosting the user's application or is stored in a distributed database spread across the event driven network.
Also, under this push notification invention the user can send the search query to either all the users in the network or to a specific group of users. The user can specify the radius within which the search is to be conducted. The application allows a user to easily perform off-line zip code look-ups, and distance and radius calculations.
Also, under this push notification invention when a successful match between the attributes occurs, the two users can continue the transaction external to the network, thereby eliminating any mediator between the interested parties.
Also, under this push notification invention, the user applications can include computers, personal digital assistants, wireless handsets, landline phones and other forms of computing and communicating equipments. Notifications can be sent between multiple types of user applications.
Also, this push notification invention allows the optional rating of the sellers by individual buyers without any centralized intervention. When a search is initiated, higher rated sellers will be listed above lower rated sellers, with the seller-rating data being stored, like the match information, at the end-points of the network.
Also, this push notification invention allows the user to create and send out multiple search queries using the same user interface window. This allows the user to conduct multiple transactions simultaneously.